Make CELERY_BEAT_SCHEDULE the source of truth for the enabled flag on
imported tasks: removing-then-re-adding a task to the configuration
re-enables the existing row, instead of leaving it stuck in the
auto-disabled state from the previous orphan-cleanup pass. The admin
warning banner already advertises this revert-on-restart behavior.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

…attern

Add a regression test for the case where a previously valid beat_schedule
entry is edited into an invalid form: the existing DB row must be disabled,
not left running on the now-stale schedule.

While here, refactor the surrounding tests in the class to instantiate the
scheduler once and call setup_schedule() to reprocess config changes,
rather than re-instantiating the Scheduler each time.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

The trailing ``self._schedule = {}`` / ``self._heap_invalidated = True``
in ``setup_schedule`` intended to force a rebuild after
``_disable_removed_from_configuration``, but it left the scheduler in a
broken state.

By the time those lines ran, the earlier ``self.schedule`` access from
``install_default_entries`` had already flipped ``_initial_read`` to
False. Clearing ``_schedule`` alone is not a rebuild trigger -- on the
next access the property goes through the ``elif schedule_changed()``
branch, which returns False (``_last_timestamp`` was just set to the
current ts, so ``ts > ts`` is False), so the empty dict was returned.
That made 10 tests in ``test_DatabaseScheduler`` /
``test_DatabaseSchedulerFromAppConf`` fail with ``KeyError`` /
``assert {}`` on what should be a populated schedule.

Invalidation is already handled correctly:
``_disable_removed_from_configuration`` calls
``PeriodicTasks.update_changed()`` whenever it disables something,
which bumps the change timestamp and makes the next
``schedule_changed()`` return True -- triggering the normal rebuild
path that also clears the heap.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>